The destructive surface was Tailwind red-600 verbatim (chroma 0.245,
near the sRGB gamut edge), which vibrates against white and reads
generic next to this project's warm palette. It now sits at chroma 0.20
in light and a lighter 0.17 in dark, which keeps unmistakable danger
semantics without shouting.

Dark mode also faded the fill to 60% opacity, compositing to a dusty red
that read closer to disabled than dangerous, on the one control that
should look most certain. Attenuation is already this kit's disabled
vocabulary, so the dark variant is gone and dark uses the full token,
which is tuned lighter for dark backgrounds.

Fixes a latent trap alongside: dark --destructive-foreground was a mid
red where light is near-white, so any component painting
text-destructive-foreground on bg-destructive would have rendered red on
red. Nothing hits it today only because the button hardcodes text-white.

Applied to both the registry theme and the gallery's preview scope,
which is a hand-maintained mirror rather than a generated one.

The destructive button rendered a faded, dusty red on a near-black
surface, reading closer to disabled than to dangerous on the one control
that should look most certain.

--destructive plays two roles that pull its lightness in opposite
directions: a FILL behind --destructive-foreground, and TEXT on a card.
In dark mode the text role needs it light, which leaves it too light for
white text on the fill. shadcn resolves that with dark:bg-destructive/60,
fading the fill until white clears AA, so the opacity was quietly doing
contrast work rather than muting a colour.

Pair the fill with its own foreground token instead. Dark now runs a
full-strength light red with DARK text, light keeps a deeper red with
near-white text, and both roles are legible with no compositing trick.
The dark --destructive-foreground was also unusable before this (a mid
red, so anything honouring the token pair painted red on red); nothing
hit it only because button.ts hardcoded text-white.

Chroma drops from Tailwind red-600's 0.245, which sits near the sRGB
gamut edge and vibrates against white, and the hue shifts marginally off
orange so it does not blur into the brand accent.

The new test converts the real tokens through OKLab to sRGB and asserts
the WCAG ratio for every pairing a shipped component paints, across all
seven base colours. A bad hand-edited oklch() triple looks fine in a
screenshot and fails only for the people who most need it not to.

The styling recipe's example palette declares fill tokens without their
`-foreground` halves, so an app that follows it and then uses a ui class
helper gets a filled variant whose text colour is undefined and falls
back to whatever it inherits.

That was survivable while the destructive variant hardcoded white, and
it is not anymore now that the variant honours its token. The example is
a good demonstration of why: its red is deep in light and light in dark,
so one fixed near-white foreground would read 6.5:1 in light and 1.7:1
in dark. The two halves have to flip together.

The skill lives canonically at the repo root and is bundled into the CLI
at prepack, so a scaffolded app picks this up with no second edit.

Review found the base-colour contrast test was reading override keys with
a `--` prefix that `base-colors.js` does not use, so every lookup missed,
the neutral palette was asserted seven times, and the test covered
nothing it claimed to.

Fixing the lookup immediately failed on a real defect: theme-stone's dark
popover is lighter than neutral's, which lifts the destructive menu
item's hover tint and drops that text to 4.47:1. Raising the dark token
from L 0.70 to 0.72 clears every base with margin (worst case 4.74:1)
and improves every other pairing, since the foreground is dark and the
tint moves only a fifth as fast as the text.

Also cover the two consumers the first version missed. The destructive
menu item on its own tint is the tightest pairing in the kit, which is
exactly why leaving it uncovered was wrong.

Drop the ratios from the button comment rather than correcting them: one
was already stale by a point, and a number duplicated from a test is a
number that goes wrong the next time a token moves. The comment now
points at the test.

Add the same skip guard the sibling registry tests use, so the file
skips rather than throwing at import where the registry is absent.

The previous commit cleared theme-stone's 4.47:1 dropdown-menu item by
raising the dark `--destructive` from L 0.70 to 0.72. That worked, but it
changed a colour every destructive surface uses to fix a problem that
lived in one component's hover tint, and it visibly washed out the
destructive button, which is the control the token exists for.

Put the red back and take the 0.02 out of the tint instead. The menu
item's own red text sits ON that tint, so lowering it from shadcn's dark
`/20` to `/15` widens exactly the pairing that was failing and touches
nothing else: worst case 4.89:1, against 4.47:1 before.

The token is a shared colour and the tint is local to one variant, so the
local surface is where a local problem belongs.

The dark destructive button had drifted into a light coral with dark
text. It cleared contrast comfortably and did not read as a destructive
button, which is the only thing that control has to do.

The cause was accepting a false constraint. --destructive has to be a
LIGHT red in dark mode, because the same token paints error text on a
near-black card. A fill under white text has to be DARK. The window
between those is genuinely empty, so I treated "one token, two roles" as
fixed and moved the foreground instead, trading the button's appearance
for a metric.

Splitting the token is the obvious answer once the constraint is stated
out loud: --destructive-fill for the button and badge, --destructive left
free for its text role. Dark mode now runs a saturated red under white
text, which is what a delete button looks like, and light mode is
unchanged because there the two values are the same.

Also revert the dropdown-menu tint divergence. theme-stone measured
4.49:1 on that pairing BEFORE any of this work, so it arrived with shadcn
rather than being caused here, and fixing it means diverging on a class
string. Tracked on its own issue instead, and the test marks that pairing
todo rather than deleting it, so the measurement stays visible.

Generalise the alpha derivation while here: the hover fill and alert
description alphas were hardcoded copies of shipped class strings, the
same gap the menu tint had. One Tailwind notch on either is enough to
cross AA with the suite still green.

The dark fill was landing deeper than any shipped design system, which
made the confirm button read heavy rather than urgent and left it barely
separated from the dialog behind it (3.68:1 against --background).

That was contrast headroom nobody asked for. Compare the reds actually
shipped for a dark destructive button: Radix red-9 sits at 3.75:1 against
white, Bootstrap at 4.34, GitHub Primer at 4.41, all below AA. Ours was
5.15, which is not a virtue when the cost is a duller button.

L 0.58 is the brightest the fill can go while white text still clears
4.5:1 (4.54). It reads essentially as GitHub's red without the AA miss,
and separation from the surface improves from 3.68 to 4.18.

The light fill is unchanged. Its surface is white, so it has no such
ceiling and no such problem.